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1.0 SUMMARY 


This document describes the design requirements for an airborne version of the Local Flow 
Management/Profile Descent path-definition algorithm. These requirements specify the processing flow, 
functional and data architectures, and system input requirements, and recommend the addition of a broad 
path-revision functional capability. The document also summarizes algorithm design enhancements and the 
implementation status of the algorithm on an in-house PDP-11/70 computer, which is similar to the 
flight-selected Norden computer. Finally, the requirements for pilot-computer interfaces, lateral path 
processor, and guidance and steering function are described. 
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2.0 INTRODUCTION 


This document is a description of the functional requirements and the current implementation status of the 
airborne Local Flow Management/Profile Descent (LFM/PD) path definition algorithm. The algorithm 
calculates either a 3D minimum-fuel arrival descent profile or a 4D minimum-fuel arrival descent profile 
when en route metering (ERM) is in effect. The profiles accommodate all air traffic control (ATC) 
clearance and procedural constraints. Local Flow Management/Profile Descent was the nomenclature 
given to the fuel-saving ATC descent procedures in effect when algorithm development was initiated. 
Although the application of profile descent procedures is currently limited to only a few runways and that 
local flow management time-based metering has been superseded by ERM, the algorithm is compatible 
with the latest Federal Aviation Administration (FA A) procedures. 

This is a report of progress made under Task Requirement A-l, Local Flow Management Avionics, of 
NASA contract NAS1-16300, to (1) extend the capabilities of the fast-time path definition algorithm 
developed under Task Requirement A- 103 of NAS 1-14880, and (2) develop an airborne-compatible 
version of the algorithm for installation on the Norden computer. The Norden, an airborne equivalent of 
the PDP- 11/70 computer, is part of the planned Transport System Research Vehicle (TSRV) B-737 
experimental test bed. The airborne algorithm requirements and proposed implementation described in this 
document represent subsequent work toward an operational airborne capability. 

Functional requirements for development of an airborne algorithm are detailed in Section 4.0. Section 5.0 
describes the proposed computer model implementation on the Norden. Airborne system interface 
requirements are described in Section 6.0. A complete description of the functional logic, computer model 
structure, and testing of the previously developed fast-time LFM/PD algorithm is contained in reference 
2 . 


2.1 BACKGROUND 

Local Flow Management/Profile Descent procedures were established on November 15, 1976, by the 
Local Flow Traffic Management national order 7110.72. The order not only specified operational 
guidelines for complying with the goal “to enhance safety, conserve aviation fuel and reduce the impact of 
aircraft noise on the local communities/’ but established a metering program as well. The function of the 
latter is to monitor the arrival flow in relation to system capacity and, if required, to meter aircraft so as 
not to exceed this capacity. When metering is to be put into effect, actual landing times are assigned 
according to calculations of estimated arrival times and the application of a prioritization rule when 
simultaneous arrivals are predicted to occur. A landing time is translated into a crossing time at one of 
several published waypoints known as meter fixes, which may require imposition of ATC delay for the 
aircraft to make good the time. 

Profile descent procedures were published at Denver, Atlanta, St. Louis, Los Angeles, Miami, and San 
Francisco. Prototype time-based metering programs were developed at Denver and Ft. Worth centers. The 
metering function has subsequently been integrated into the NAS stage A software and is now available at 
all centers as ERM. Beyond these current metering programs, the FAA has several advanced flow 
management concepts under study or development. These include terminal metering, automated en route 
ATC, and terminal area tactical execution. These concepts form the basic building blocks for evolution of 
the ATC system flow management function from today’s time-based metering to the 1990 to 2000 Air 
Traffic Management system. 


2.2 NASA ADVANCED TRANSPORT OPERATING 
SYSTEMS (ATOPS) LFM RESEARCH 


The LFM avionics research program was established to define the airborne navigation and guidance 
capabilities needed for efficient operation in the ATC flow management system under development. The 
NASA Local Flow Management avionics research plan is shown in Figure 1 . This plan was developed 
under NAS1-14880, TR AB-11. Subtasks 1 and 2 under NAS1-14880 have been completed and a 
contractor report was published, which delineated the major areas to be addressed in the LFM research 
plan (ref. 1). Subtasks 3 through 9 identified in Figure 1 are being pursued as part of the long-range 
research effort. 

The design of the basic, generalized algorithm to provide path definition computations was completed in 
July 1979. The development of additional capabilities (including holding and path stretching 
considerations) and refinement of the algorithm based on analysis, simulation and flight test results were 
completed in July 1980 (ref. 2). The airborne algorithm design requirements were specified in December 
1981 (ref. 3). These requirements are summarized in Sections 4.0 and 6.0. The work to install the basic 
algorithm on an in-house PDP-ll/70 was begun in August 1981. The status of the airborne algorithm 
activity is summarized in Section 5.0. 

2.3 AIRBORNE ALGORITHM DEVELOPMENT TASK 

The algorithm design requirements, as described in Section 4.0, make a demanding core size requirement 
on the flight computer. The current CYBER FORTRAN (fast-time) version requires 151,000 octal words. 
Features described in Section 4.0 have been incorporated into the basic algorithm, except for some path 
revision capabilities (described in subsection 4.5) that are to be used in response to changes in the planned 
descent due to weather or traffic. Implementation of the algorithm on the PDP-1 1/70 requires reduction to 
a maximum work space of 28,000 octal words by overlay management and other techniques. This 
implementation is described in subsection 5.2. Recommended additional capabilities to support path 
revisions are described in subsection 5.3. 
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Subtask 



Figure 1. Local Flow Management Avionics Research Plan 




3.0 SYMBOLS AND ABBREVIATIONS 


0 

A\p 

ADS 

AFDI 

ARTCC 

ATC 

ATOPS 

CAS 

C D 

CDU 

EADI 

EHSI 

EPR 

ERM 

ETA 

F n /6 

FAA 

FMC 

FMS 

a 

o 

GMT 

IRS 

ISA 


bank angle 
coarse change 
air data system 

automatic flight director indicator 
air route traffic control center 
air traffic control 

Advanced Transport Operating Systems 

calibrated airspeed 

drag coefficient 

control and display unit 

electronic attitude/director indicator 

electronic horizontal situation indicator 

engine pressure ratio 

en route metering 

estimated time of arrival 

corrected net thrust 

Federal Aviation Administration 

flight management computer 

flight management system 

acceleration due to gravity 

Greenwich Mean Time 

inertial reference system 

International Standard Atmosphere 



kcas 

LFM/PD 

MFT 

MSL 

NAS 

NASA 

nmi 

N, 

rpm 

s 

STAR 

At 

AT 

TAT 

TNAV 

TOD 

TSFC 

TSRV 

V 

V ef 

V o 

3D 

4D 


knots calibrated airspeed 

Local Flow Management/Profile Descent 

meter fix time 

Mean Sea Level 

national airspace system 

National Aeronautics and Space Administration 

nautical miles 

airplane turbine rpm 

revolutions per minute 

elapsed distance 

standard arrival route 

elapsed time 

change in absolute temperature 
total air temperature 
time navigation 
top-of-descent 

thrust-specific fuel consumption 

Transport System Research Vehicle 

ground speed 

entry fix airspeed 

initial airspeed 

three-dimensional 

four-dimensional 



4.0 AIRBORNE ALGORITHM DESIGN REQUIREMENTS 

This section describes the airborne Local Flow Management/Profile Descent (LFM/PD) algorithm design 
requirements. The requirements define the needed functional characteristics in an operational context and 
the interaction among the algorithm functional elements, pilot inputs, and sources of data. Functional and 
data architectures are also provided. In order to increase algorithm flexibility, the capability to make 
revisions to the flight plan (including during descent) is recommended for addition to the basic functions of 
the fast-time version described in Reference 2. 

4.1 ALGORITHM PROCESSING FLOW 

The flow of the various algorithm processes is depicted in Figure 2. This subsection describes the 
sequence of the algorithm’s functional elements from the moment of algorithm initiation to the display of 
summary data. Subsection 4.4 describes the sequence of pilot inputs, which include activation of the 
algorithm, review of summary path and performance data, and subsequent action (communication to the 
flight management software to engage the path or accept revised inputs). 

A description of the airborne descent algorithm processes follows. It is assumed that the pilot has 
requested a profile descent calculation on the control and display unit (CDU). 

4.1.1 PRESENT POSITION CONDITIONS 

When the profile descent algorithm is activated, parameter values defining the current airplane state are 
immediately determined by the airplane subsystems: 

(1) airspeed 

(2) pressure altitude 

(3) lateral position (latitude, longitude) 

(4) gross weight 

(5) time 

These data form the basis for calculating airplane state at the entry fix. 

4.1.2 ENTRY FIX CONDITIONS 

The entry fix is the point at which the descent-path initial conditions are defined. It provides a waypoint 
reference where the projected airplane state must be a boundary condition constraint on the profile 
computation solution. The fix is placed at five minutes ahead of present position, allowing sufficient time 
for all requisite inputs and algorithm computations to take place, and for computed path engagement 
(coupling to the autothrottle and autopilot). Entry fix calculations should yield: 

(1) lateral position 
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(2) gross weight 

(3) time 

Entry fix speed and altitude are assumed to be the same as those at present position (paragraph 4.1.1). 

4.1.3 GEOMETRY FILE 

The destination airport and arrival procedure (meter fix and runway specifications) are supplied as part of 
the preflight inputs. The arrival procedure may be published as a profile descent or a standard arrival route 
(STAR). Algorithm utility will be extended by the additional capability to change the airport and path 
through the CDU prior to algorithm activation. The nominal arrival path procedure from the navigation 
data base will have been loaded into the path buffer. Any commanded geometry changes will automatically 
load the appropriate data into the buffer. 

4.1.4 WIND AND TEMPERATURE MODEL PROCESSING 

Currently, the algorithm updates wind and temperature forecasts, which can be obtained as much as 18 
hours prior to departure. The forecast data can be loaded into an input file during preflight and later 
changed when the algorithm on activation updates the forecast with cruise wind and temperature 
measurements. A correction function is assumed which linearly decreases from the measured value at 
cruise altitude to the forecast value at aimpoint altitude. Thus, the forecast winds and temperatures are 
adjusted proportionally with altitude. The option to input (via CDU) revised forecasts can be exercised. A 
linear wind model assuming measured wind at cruise and zero ground wind, and a temperature model 
assuming ISA + AT (where AT is the temperature variation at cruise) are the default models when no 
forecast data are provided. 

4.1.5 INITIALIZATION DATA PROCESSING 

At this point, the algorithm requires the various pilot-supplied initialization inputs that specify the descent 
conditions. Status flags for metering, holding, and icing are processed, along with the appropriate data 
that define each state. The current geometry is also processed, including any revisions made prior to 
algorithm activation. 

4.1.6 SPEED TRANSITION MODEL CONSTRUCTION 

The model that defines the Mach-to-CAS transition altitude (as a function of airspeed) is constructed at 
this stage of the processing flow. An important design consideration was to make maximum use of the 
available time envelope, consistent with Mach/CAS procedures and gross weight, by the model’s defining 
a constant CAS descent at minimum speed and the fastest Mach/CAS descent at maximum speed. An 
empirical linear relationship (altitude versus true airspeed) assumed between the two limits, as depicted in 
Figure 3, closely approximated the Mach/CAS families of descent speed schedules suggested in the B737 
flight operations manual. 
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4.1.7 PATH CALCULATION 


The descent path parameters, which conform to all ATC, airplane performance, and weather constraints, 
are calculated. The computed descent path is composed of two sections: the high profile, and runway 
profile. The former is defined as that portion from cruise altitude down to the terminal area, while the 
latter is the terminal area descent path. More importantly, the runway profile includes the approach path 
from the aimpoint outbound to the last waypoint where ATC speed constraints are published. The aimpoint 
is the target fix where the algorithm requires altitude and speed constraints. In contrast to the procedural 
nature of the runway profile, the high profile allows timed descents over a wide range of speed schedules 
in order to accommodate a time assignment at the meter fix. Data stored in the performance (airframe and 
engine) data bases are used to determine the path. The runway and high profiles for a typical descent at 
Denver Stapleton International Airport are depicted in Figure 4. 

4.1.8 PATH SUMMARY DISPLAY 

The algorithm will display a summary of the path data for pilot preview. Section 6 discusses the display in 
the context of the interface required with the CDU. 

4.2 FUNCTIONAL ARCHITECTURE 

The algorithm functional components include the following: 

(1) navigation data input 

(2) atmosphere modeling 

3) profile and path initialization 

(4) icing determination 

(5) speed transition model construction 

(6) runway profile path construction 

(7) high profile path construction 

(8) display generation 

The elements of each component are defined in Figure 5. 

4.3 DATA ARCHITECTURE 

All the data tables and airplane constants used in the fast-time descent algorithm are also required for the 
airborne version data base. The data required for the descent calculations are categorized in Figures 6, 7, 
and 8 according to navigation, engine, and airplane characteristics. 
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Figure 3. Speed Transition Model Construction 
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Figure 4. Runway and High Profiles for a Typical Profile Descent (KEANN 35R, 
Denver Stapleton International Airport) 





DESCENT PATH PREDICTION ALGORITHM 


— Navigation Data Input 
Airport Selection 

-| Path Selection 

Geometry and ATC Constraints 

* Atmosphere Mode! Construction 

— Vertical Wind Profile 

— Vertical Temperature Profile 

Profile and Path Array Initialization 

— Gross Weight Initialization 

— Geometry Revision 

— Altitude Assignments 

— Speed Restrictions 

— Entry Fix and Aimpoint Speeds 

— Airport Elevation 

Icing Requirements Definition 
Speed Transition Model Construction 
Runway Profile Path Construction 

High Profile Path Construction 

— Metering-Fix Time Assignment 

— Nonmetered Fuel-Efficient Path Definition 

— Descent Path Definition to Make Good MFT 
Delay Profile 

Holding 

Path Stretching 
No-Delay Profile 

Display Generation 


Figure 5. Algorithm Functional Structure 


NAVIGATION DATA 


Airport 1 

— Airport Elevation 

— Magnetic Variation 

Profile Descent (STAR) (1,1) 

— — Waypoint List 

Aimpoint I.D. 

Entry Fix I.D. 

""I”" Standard Holding Fix I.D. 

““ Holding Speeds 

Inbound Leg Holding Magnetic Course 

Standard Meter-Fix I.D. 

Segment Magnetic Courses 

Segment Distances 

Waypoint Altitude Restrictions 

Runway Profile Speed Constraints 

— Profile Descent (STAR) (1,2) 

i 

i 

i 

— Profile Descent (STAR) (l.m) 

t 

i 

Airport 2 

i 

i 

i 

Airport n 

i 

i 
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Figure 6. Navigation Data Base Architecture 



ENGINE DATA 


Fuel Flow Tables 

— Idle Fuel Flow vs Mach, Altitude 

— Non-ldle TSFC vs Normalized Thrust, Mach. Altitude 

EPR Tables 

— EPR vs Corrected N 1( Mach. Altitude 

— Max Cruise EPR vs TAT 

— Max Climb EPR vs TAT 

Thrust Tables 

— Idle Thrust vs Mach, Altitude 

— Installed Net Thrust vs EPR, Mach 

Net Thrust Correction vs Mach, Altitude 


Figure 7. Engine Data Base Architecture 


AIRFRAME DATA 


Gross Weights 

— Minimum Zero-Fuel Weight 

— Maximum Operating Weight 

Speed Limits 

— Slow Speed 
Flap Extension 

Slow Speed Mach Buffet vs Altitude. Weight 

— Fast Speed 

Maximum Operating Mach 

Maximum Operating Equivalent Airspeed 

Thrust-Limited True Airspeed vs Weight, Altitude, Temperature 

High-Speed Mach Buffet vs Altitude, Weight 

Wing Area 

Number of Engines 

Service Ceiling Altitude 

Drag Poiars 

Maximum Co vs Equivalent Airspeed 


Figure 8. Airframe Data Base Architecture 



4.4 SYSTEM INPUT SPECIFICATIONS 


Figure 9 illustrates the proposed sequence of pilot inputs and actions. Table l is a detailed summary of the 
inputs required by the algorithm to fulfill its path calculation function. The subsystem interfaces that are 
required with the path definition functions include: 

(1) inertial reference system (IRS) 

(2) air data system (ADS) 

(3) internal clock 

(4) on-line data bases 

(5) fuel totalizer 

(6) pilot inputs 

Pilot entries on the CDU are assumed to be made through dedicated function keys or by menu selections. 
The following text elaborates on each entry type. 

4.4.1 PREFLIGHT INPUTS 

The FAA supplies twice-daily wind and temperature forecast data for 62 U.S. weather stations. The 
appropriate data for all destination airports are loaded into an input file. In addition, for the purposes of 
the descent calculations, the pilot should provide, through CDU inputs, the following data: 

(1) city pair 

(2) planned arrival route (including meter fix and runway) 

(3) forecast winds and temperatures at the destination airport 

(4) current Greenwich Mean Time (GMT) 

(5) preliminary meter fix time (if applicable) 

(6) airplane zero-fuel gross weight 

(7) cruise altitude 

4.4.2 AIRPORT/PATH VERIFICATION 

The default combination of destination airport, profile descent procedure or STAR, and runway provided 
during preflight is assumed unless changed by pilot input. The navigation data base will contain alternative 
procedures at the selected airport as well as other airports with applicable paths. Selection of airport, 
meter fix, and runway will be sufficient to cause insertion of an alternate descent procedure. The 
procedure will be displayed waypoint by waypoint on the CDU for pilot review: waypoint sequence. 
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Figure 9. Sequence of Pilot Inputs and Actions 





Table 1. Pilot/Avionics/Data Base Input Specifications 


Function 

Default (Internal) 

Source 

Pilot Input Via CDU 

(1) Selection of arrival 





Selection 

algorithm 




(2) Destination airport 

Pre-flight loaded 
airport identifier 

Pre-flight information 
file 

— 

(3) Profile descent path 
(approach and runway) 

Pre-flight loaded 
meter fix-runway 

Pre-flight information 
file 

Alternate path 

(4) Icing indication 

No icing anticipated 

— 

Icing anticipated 

(If icing anticipated ) 




N, selection 

55% N, 

— 

Alternate N, setting 

Vertical 

region 

20,000 feet to surface 

— 

Upper and lower altitude 
limits (MSL) 

(5) Metering indication 

No metering 

— 

Metering in operation 

(If metering in progress:) 




Meter fix 
specification 

Pre-flight selected 
meter fix 

Pre-flight information 
file 

Revised meter fix 

Meter fix time 

Pre-flight loaded MFT 
(if available) 

Pre-flight information 
file 

Revised ATC-assigned 
MFT 

(6) Holding indication 

No holding anticipated 

— 

Holding anticipated 

(If holding ) 




Holding fix 
specification 

Published fix for 
selected path 

Navigation data base 

Alternate fix outbound 
of meter fix 

Inbound holding 
magnetic course 

Inbound course of 
published holding 
! fix for selected path 

Navigation data base 

Course of alternate 
holding fix inbound 
leg 

Turn direction 

Published direction 

Navigation data base 

Opposite direction 

Holding mode 
selection 



Slacking, ATC-assigned 
altitude, or fuel-efficient 
altitude holding selection 








to 

o 


Table 1 . Pilot/Avionics/Data Base Input Specifications (Continued) 


Function 

Default (Internal) 

Source 

Pilot Input Via COU 

(If stacking ) 
Stack altitudes 



Top/bottom altitudes (MSL) 

(If ATC-assigned altitude:) 
Assigned altitude 

— 

— 

ATC-assigned altitude 
(MSL) 

(NOTE: If minimum-fuel altitude holding (paragraph 4.4.3. 3) 

) is assumed, algorithm will compute the holding altitude.) 


Expected delay 
Holding airspeed 

(7) Algorithm activation 

(8) Current position 

(9) Current gross weight 

i 

(10) Current time 

(11) Current speed 

(12) Entry fix Mach 

(13) Entry fix gross weight 

(14) Entry fix position 

(15) Entry fix time 


Recommended speed at 
holding altitude (if stack, 
bottom altitude) 


(Pre-flight loaded zero-fuel 
weight] ♦ (current fuel] 


Current cruise Mach 


(Gross weight from 
Item (9)) - [predicted fuel 
burn after 5 minutes] 

(Current lateral posilion] 

* |elapsed distance after 5 
minutes], altitude same as 
present altitude 

ETA based on current lime 

* 5 minutes 


Airframe data base 


Latitude and longitude from 
IRS; altitude from ADS 

Zero-fuel weight from 
pre-flight information file; 
fuel remaining from fuel 
totalizer 

Internal clock 

Air data system 

Speed recorded at present 
position (Item 11) 

Fuel flow from engine 
data base 


Altitude recorded at present 
position (Item 8) 


Time recorded at present 
position (Item 10) 


Delay (minutes, seconds) 
Alternate airspeed (kcas) 

Activation 







Table 1. Pilot/Avionics/Data Base Input Specifications (Concluded) 


Function 

Default (Internal) 

Source 

Pitot Input Via CDU 

(16) Weather model 
computations 

(17) (If holding or path- 
stretching required) 

(Holding: same input 
session as Item 16) 

(Path stretching ) 

Pre-flight loaded wind and 
temperature forecasts 
adjusted by cruise 
measurements 

Forecasts from input file 
Cruise wind from IRS 
Temperature at cruise from 
air data computer 


Offset starting point 

— 

— 

Lateral position 

Lateral offset limit 

10 nmi 



Alternate offset limit 

Turn direction 

Right 

— 

Left 



courses, distances, altitude and profile descent speed restrictions, aimpoint (outer marker) speed, airport 
elevation, and published holding and meter fix identification. Prior to algorithm activation, the pilot may 
make any required changes to the flight plan. The revised path may be converted to the active flight plan 
by appropriate pilot action on the CDU. 

4.4.3 PATH INITIALIZATION 

These data determine the unique characteristics of a descent under given procedural and climatological 
conditions. If any algorithm default value needs modification, the alternate value is entered on the CDU by 
the pilot. This interactive session constitutes the bulk of any required pilot inputs. The default operational 
assumptions are as follows: 

(1) no icing 

(2) no metering 

(3) no holding anticipated 

These inputs as well as those of paragraph 4.4.2 can be made at any time prior to activating the algorithm. 

4.4.3.1 Icing 

The default assumption is that an icing condition is not anticipated throughout the descent. Changing the 
default causes the icing page to be displayed. The icing default values are: 

(1) 55 percent Nj (for engine anti-ice) 

(2) icing region between 20,000 feet MSL and the surface 
but may be modified via the CDU. 

4.4.3.2 Metering Indication 

The default status is ono metering.a If the metering page is called up, these defaults then are displayed: 

(1) nominal meter fix of the descent path selected 

(2) preliminary meter fix time (if provided) 

Changes must be made on the CDU. 

4.4.3.3 Anticipated Holding Indication 

The default assumption is that no ATC holding is in effect. When the default is changed, the holding page 
is subsequently displayed, with the following holding defaults assumed: 

(1) published holding fix for selected path 
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(2) published holding fix magnetic course 

(3) published turn direction 

Changes to any default are made on the CDU. Any waypoint outbound of the meter fix may be selected as 
the holding fix. Also, on the same page, the holding mode selection must be made: 

(select one:) 

(1) stack holding (multiple-airplane holding) 

(2) ATC-assigned holding altitude (single-airplane holding) 

(3) minimum-fuel holding altitude (single-airplane holding) 

The minimum-fuel holding altitude is the holding fix altitude intersecting the minimum-speed descent 
path. After completion of this page, the display will request the following, depending on the holding mode 
selection: 

(for stacking:) 

(1) top and bottom stack altitudes (MSL) 

(2) anticipated delay (minutes, seconds) 

(for ATC-assigned altitude:) 

(1) assigned altitude (MSL) 

(2) anticipated delay (minutes, seconds) 

(for minimum-fuel altitude:) 

(1) anticipated delay (minutes, seconds) 

Anticipated delay is used by the algorithm to help estimate an aimpoint gross weight. The algorithm will 
calculate the fuel-efficient altitude after the algorithm is engaged. Holding speed will be a function of the 
holding altitude. In a holding stack, the speed is based on the bottom altitude. 

The case of pilot-initiated holding required to absorb excess ATC delay is handled in paragraph 4.4.9. 

4*4.4 ALGORITHM ACTIVATION 

After all input requirements are met, the pilot will activate the algorithm on the CDU to calculate the 
descent path. No further pilot inputs are required, unless the algorithm cannot compute the path within the 
aeroperformance limits of the airplane. 
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Prior to the entry fix, five minutes are allowed for the algorithm to complete the descent path calculation 
and display results, the pilot to request a clearance from ATC, ATC to issue its clearance, and the pilot to 
engage the algorithm. The algorithm should be provided with present position data (latitude and longitude) 
by the inertial reference system, current speed and altitude by the air data system, and current time by the 
internal clock. Current gross weight can be computed by adding the zero-fuel gross weight provided 
during preflight and the current fuel totalizer reading. These values are used to predict airplane state at the 
entry fix. 

There is some latitude as to when the algorithm can be activated. However, because the entry fix is 
positioned at a fixed time interval in the future, the moment of algorithm activation should not be so far in 
advance that the cruise wind and temperature measurements might be significantly different than those at 
the top-of-descent (TOD). Nor, in the case of a metered descent, should it be so late that a spoiler descent 
would be required to meet the time objective. 

The activation window might be determined based on prior experience or calculation and referenced to an 
average clean-idle descent time to the meter fix (if a metered descent) or to a fixed distance from the 
airport. 

4.4.5 ENTRY FIX CONDITIONS 

Speed and altitude at the entry fix are assumed to be the airplane speed and altitude at the time of 
algorithm activation. Entry fix gross weight is calculated by subtracting from the current gross weight the 
expected fuel burn over five minutes. Fuel burn rate and the number of engines are obtained from the 
engine and airframe data bases, respectively. The entry fix position is determined by the elapsed distance 
over five minutes and the current cruise speed. 

4.4.6 WEATHER MODEL COMPUTATIONS 

The wind and temperature forecasts, provided either during preflight or revised en route, are updated by 
current cruise wind and temperature, as described in paragraph 4.1.4. Current wind is supplied by the 
inertial reference system (IRS); current static air temperature is computed by the air data system (ADS). 
No pilot inputs are required. If no forecasts are supplied, the wind model is assumed to be the wind 
measured at cruise altitude, decaying linearly to zero on the ground. 

4.4.7 SPEED TRANSITION MODEL CONSTRUCTION 

The speed transition model (Mach to CAS) requires the determination of the airplane low- and high-speed 
limits, primarily as a function of gross weight, as described in paragraph 4.1.6. The low-speed limit at the 
maximum service ceiling altitude (35,000 feet for the 737-100) is the maximum of the procedural flap 
extension speed and low-speed Mach buffet. The high-speed limit is the minimum of the high-speed Mach 
buffet, maximum operating true airspeed, maximum operating Mach, and thrust-limited speed. The 
service ceiling altitude and ail the speed limits are to be obtained from the airframe data base. 

4.4.8 RUNWAY AND HIGH PROFILE CONSTRUCTION 

The segment calculation modules, whose functions are described in greater detail in Reference 2, employ 
airplane, navigation, weather, and engine data. Engine data consist of idle thrust fuel flow versus Mach 
(and altitude); non-idle fuel flow versus normalized thrust (and Mach and altitude); idle thrust versus 
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Mach (and altitude); engine pressure ratio (EPR) versus corrected Nj (and Mach and altitude); installed 
net thrust versus EPR (and Mach and a thrust correction as a function of Mach and altitude); maximum 
climb EPR versus total air temperature (TAT); and maximum cruise EPR versus TAT. Airplane data are 
low-speed and high-speed performance envelope speed limits, both as a function of weight and altitude; 
maximum spoiler drag coefficient versus equivalent airspeed; drag polars; number of engines; maximum 
rate of descent; and wing area. Airplane, navigation, and engine data are to be available from the data 
base. 

4.4.9 REQUIRED DELAY 

When the algorithm determines that increased path distance is required to make good a meter fix-time 
assignment, additional pilot inputs are needed depending upon the delay mode selected by the algorithm. 

4.4.9. 1 Holding Mode 

The inputs are the same as described in subparagraph 4. 4. 3. 3, except that no input is required 
(appropriate) for anticipated delay, since the algorithm computes the delay. 

4.4.9.2 Path Stretching Mode 

Path stretching is assumed to be carried out at cruise altitude, prior to the TOD. The pilot needs to specify 
the lateral position at which path stretching is to begin, the initial turn direction, and the maximum lateral 
excursion from the nominal path. The last input will most likely be the result of an ATC clearance 
(10-nautical mile (nmi) offset is the default value assumed by the algorithm). The algorithm will 
automatically adjust the. time between the entry fix and TOD by the amount of path-stretching delay. 

4.5 PATH REVISION REQUIREMENTS 

Changes in the ATC environment may require another path calculation to satisfy new constraints. The 
value of this aspect of an on-board flight management computer system will depend on the expediency 
with which both the pilot can define new inputs and the algorithm can consequently redefine the path after 
the appropriate ATC clearances have been issued. The required changes must be known far enough in 
advance to allow adequate time for the pilot to enter the new input dataset. Algorithm reinitialization is 
depicted as part of the processing flow in Figure 2 and the sequence of pilot inputs in Figure 9. 

A reinitialization capability must provide the required flight management computer (FMC) interfaces to 
disengage the previously engaged path and evaluate the greater restrictions placed on the path-definition 
process as the airplane approaches the meter fix. On reinitialization, the airplane must transition from the 
old engaged path and meter fix time (MFT) to a new path and, possibly, time. The significant impact on 
making good the (new) MFT must be considered, since the available time delay margin and distance will 
have shrunk. 

For a metered path, any path revision will decrease the probability of making good the MFT. The 
algorithm will search for another speed schedule to stay within the original time constraint while still 
conforming to airplane performance and ATC restrictions. If no speed schedule will satisfy the time 
requirement, a new time must be assigned by ATC to continue metering. 
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Several operational situations will prompt the use of path (and time) revision options. The development of 
a weather cell or clear air turbulence zone may require circumnavigation by selecting a different arrival 
path, or flying a modification to or lateral offset from the nominal arrival path. Where traffic permits, the 
options may be exercised to delete a waypoint, fly direct to another waypoint, or eliminate altitude and 
speed restrictions. Nonstandard situations may require the use of a lateral offset, arrival path modification, 
“direct to,” waypoint deletion, or altitude and speed constraint change options. The lateral offset feature 
can be used when ATC approves overtaking a slower airplane. 

When an unexpected system delay arises, the airplane may have to hold, fly a lateral offset (path stretch), 
or be assigned a new MFT. The algorithm decision logic must take into consideration the following: 

(1) If a MFT is assigned when no metering was previously in effect, or if a later time assignment is 
made to supersede the original one, a (new) speed schedule should be computed. If a slow-speed 
schedule cannot satisfy the time constraint, then holding or path stretching may be needed. 

(2) If stack holding is already in effect and the airplane is not holding yet, then new holding parameters 
can be calculated based on the new MFT. 

(3) If stack holding is already in effect and the airplane is in the stack, a procedure should be defined for 

incorporating the extra required delay into the remaining holding path after the next holding fix 

crossing (the timing reference, as mechanized in the LFM/PD holding logic). 

(4) If stack holding is already in effect and the airplane has just left the stack, speed recalculation, 
waypoint insertion, or path stretching (lateral offset) may be required. 

4.5.1 LATERAL PATH REVISION 

The algorithm capability should be extended to include changes in the descent phase of the lateral flight 
plan. 

Lateral path revision capabilities may take the form of a change in the destination airport, a change of the 
profile descent path (different approach, including new meter fix or meter-fix outer-marker combinations), 
partial modifications to the nominal descent path, changes at a waypoint, and flying lateral offsets. The 
following sections also indicate applicability to three-dimensional (3D) and four-dimensional (4D) 
path-prediction modes. 

4.5.1. 1 Airport Change 

Normally, at the time the descent algorithm is to be initiated, an airport change would not be required by 
ATC or the pilot. Therefore, this capability should be exercised during prior flight phases. 

4.5.1.2 Arrival Path Change (3D and 4D) 

The navigation data base will contain alternative paths at a profile descent airport. If an arrival path 
change is invoked sufficiently ahead of the TOD, the algorithm can accommodate the modification. 
However, once descent has begun, the algorithm must be reinitialized, and the new path must be specified 
as in subparagraph 4.5. 1.3. For a 4D descent, when the new arrival path has another meter fix, a new 
MFT must be specified. 
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4.5. 1.3 Partial Changes to Descent Path (3D and 4D) 

When the algorithm is reinitialized, the flight plan modification input procedure will be required. Another 
entry fix will be defined by the algorithm. For a timed descent, the meter fix is assumed to remain the 
same, otherwise an arrival path modification is implied (subparagraph 4.5. 1.2). 

4.5. 1.4 Changes at a Waypoint (3D and Some 4D) 

The algorithm should make provisions to allow changes at a designated waypoint. These modifications 
could include inserting or deleting a waypoint, requiring holding at the waypoint, and specifying a “direct 
to” leg to another waypoint. The algorithm must be reinitialized and the required change made directly on 
the flight plan CDU display page. Time-based descents may use the waypoint insertion or holding path 
modification options. 

4.5.1.5 Lateral Offset (3D and 4D) 

In a lateral offset feature, the pilot must specify the waypoint or lateral position at which the offset is to 
begin, the offset distance, and turn direction of the offset from the waypoint or lateral position. The input 
procedure is the same as that for specifying path-stretching parameters. The waypoint selection will be 
among those defined in the navigation data base; the lateral position specification (phantom waypoint) will 
include its latitude and longitude or its radial and distance from a navigational aid or other defined 
waypoint. The airplane will continue flying a lateral offset path until the pilot, via the CDU, commands 
either a return to the nominal path or a "direct to.” Otherwise, the algorithm could cause the airplane to 
return automatically to the original path at the waypoint prior to the runway outer marker. For a 4D 
descent, the complete offset path must be specified by the pilot. 

4.5.2 VERTICAL PATH REVISION 

Vertical path revision capabilities include changing programmed ATC waypoint altitude and speed 
constraints. In addition, when the airplane makes an early or late TOD, a method for computing a new or 
partial path will be required. 

4.5.2. 1 Changes to Altitude Constraints (3D Only) 

Changes to altitude constraints include changing or deleting existing constraints. No additional vertical 
path modification capability is required when altitudes of stored waypoints are used in a lateral path 
revision, since altitude constraints at these waypoints are contained in the data base. 

4.5.2.2 Changes to Speed Constraints (3D Only) 

The capability to modify speed constraints should be provided to accommodate emergency or traffic-free 
descents. The option to change or eliminate the constraint at an individual waypoint or eliminate the limits 
at all waypoints in the descent flight plan will be available. 
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4.S.2.3 Early or Late TOD (3D and 4D) 


If the TOD position has to be changed, the algorithm must be capable of computing the new descent path 
segment to capture the nominal path or, when metering is in effect, to determine a new speed schedule 
employing thrusted or spoiler segments. The above capability may require the new TOD position to be 
supplied by the pilot prior to the descent. 

4.5.3 MFT REVISION 

Changes to the MFT assignment should be accommodated to extend the 4D capability of the algorithm. If 
a change can be incorporated prior to the new TOD. then the new path can usually be determined by a new 
speed schedule (with a possible delay path). If the MFT is changed after the airplane has begun its descent, 
then the problem becomes one of redefining a new path from some future waypoint inbound. 
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5.0 AIRBORNE ALGORITHM IMPLEMENTATION 


The current status of the airborne algorithm implementation effort is detailed in this section. This effort in 
its entirety requires reduction of the working core size by overlay management, the integration of path 
revision capabilities recommended in subsection 4.5, and the representation of the man-to-machine inputs 
and machine-to-machine data interfaces that are specified in subsection 4.4. The overlay task was 
undertaken first in order to partition the algorithm functionally. Preliminary testing on the reduced-core 
algorithm was completed. The recommended path revision capabilities not yet implemented are discussed 
in subsection 5.2. The input structure integration task has not been initiated. 

5.1 ALGORITHM ENHANCEMENTS AND EXTENDED CAPABILITIES 

Additional capabilities and design enhancements beyond those described in Reference 2 have been added 
to the fast-time LFM/PD baseline algorithm to provide more flexibility to an airborne algorithm. 
Significant reductions in program execution times were made possible after conducting an algorithm 
sensitivity analysis. 

The meter fix designation can now be given to any waypoint and does not need to be collocated with the 
first waypoint where an arriving airplane must comply with a speed constraint. The first speed waypoint is 
now designated as the transition fix and defines the boundary between the high and runway profiles, which 
are described in paragraph 4.1.7. 

The distance over which a required change of speed is constrained by the algorithm has been expanded to 
include more than one published waypoint. This capability allows greater changes of speed and makes 
maximum use of the time delay margin available in the flight envelope. Change-of-speed segments are 
typically required to make the transition from a descent speed to a procedural speed constraint at the meter 
fix and from the entry fix speed to a descent speed. 

Spoiler drag calculations are permitted, when applicable, over more than one segment in order to satisfy 
an altitude constraint. The algorithm normally assumes a clean airplane configuration (and idle-power 
thrust) throughout the descent. In the process of the descent path construction from the meter fix up to the 
entry point, it may not be possible for the last descent segment to make the final altitude constraint even 
with full spoilers. The algorithm then includes as many preceding descent segments as required to 
complete the descent with spoilers. 

Ia the previous fast-time algorithm version, performance data were integral files of the program. Airport 
geometry data were read in as part of each run. The algorithm architecture has been redesigned to store 
both performance and airport geometry data out of core. The structures of these data are described in 
subsection 4.3. Data segregation from the functional aspect of the program is a significant step toward 
developing an airplane-independent algorithm, inviting application to other airplane types. 

Significant reductions in algorithm execution time were achieved as a result of changes tested and 
validated by a sensitivity analysis. Alternative mechanizations to the 4D speed schedule search (to make 
good an assigned MFT) and spoiler and thrust factor computations were incorporated. Execution-time 
benefits were also derived from increased path segment integration step sizes. These changes produced no 
significant differences in time, distance, and fuel values, while reducing mainframe computer (CYBER) 
execution time by at least 70 percent for a variety of descents. 
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The speed schedule (Mach/CAS combination) to make good a MFT was originally determined by using 
the binary search technique in which the descent Mach was varied and the resultant descent time compared 
to the required descent time. The current implementation computes the trial descent Mach from an 
iteratively adjusted, linear model of delay (descent time) versus descent Mach. In each iteration, a linear 
delay versus Mach relationship is constructed from the previous test Mach and its associated delay and one 
of the limits of the previously constructed model. The Mach-to-CAS transition point is determined by the 
speed transition altitude model. 

Analogous search techniques were used to calculate the spoiler and thrust factors computed for segments 
requiring above-idle thrust or spoiler drag, respectively. In either case, a clean-idle configuration is 
insutficient to effect the descent given the ATC constraints at the two waypoints. A faster converging 
solution to the required factor is possible if a linear relationship is assumed between spoiler or thrust factor 
and resultant altitude. Then, the target altitude can be used to compute a trial factor. The trial factor 
altitude at the end of the segment computation will then be compared to the target altitude. If the difference 
is outside the acceptance criterion, then another factor versus resultant altitude model is constructed 
between the trial factor-altitude data point (just tested) and the appropriate boundary point of the previous 
model. The iteration is continued until an acceptable final altitude is obtained. 

In the calculation of the thrust factor, the initial model boundary points are taken to be the percentage of 
maximum cruise thrust required to maintain level flight and idle thrust (FACTOR = 0) with their 
associated altitudes. The initial spoiler factor model is constructed between maximum spoiler deployment 
and a clean-idle configuration. 

Each segment of a descent path calculation is constructed by integrating a sequence of intervals 
comprising the segment. A level segment calculation does a step-wise integration over time and solves for 
fuel, elapsed time, and (if an acceleration or deceleration segment) final speed over a given distance. A 
descent segment calculation changes altitude and solves for fuel, elapsed time, and (if a clean-idle descent 
segment) distance to a point-of-descent. The sensitivity analysis indicated that a significant trade of 
interval step sizes against execution time can be made without compromising the high profile descent time 
estimation accuracy. From the original 10 seconds for a level segment and 100 feet for a descent segment, 
iteration step sizes were increased to 50 seconds and 500 feet, respectively. 

5.2 INITIAL DESIGN IMPLEMENTATION 

The problem of apportioning the path definition function to 28,000 octal words suggests an overlay design 
as one possible solution. Memory management is another option. The final technique will be decided 
depending on operating system support for the Norden computer. The overlay design is presented here to 
illustrate the partitioning, which can be used to carry out the descent profile prediction function. The 
modular architecture of the algorithm lends itself to overlaying. However, execution time is increased as 
the number of overlay segments is increased, because inactive modules stored on disk must be retrieved as 
needed. 

The overlay design distinguishes between those modules, which are always resident in core (the root), and 
those required on an individual or sequential basis (the branches). The root modules consist of, or 
perform, the following: 

(1) Coordination of the path-prediction function (executive routine). 
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(2) Physical and unit conversion constants. 

(3) Storage of most recently calculated path parameters in mass storage devices. 

(4) Validation (via CDU) of input data. 

(5) Calculation of linear regression models. 

(6) Determination of a waypoint’s numerical order. 

(7) Computation of the speed transition (Mach to CAS) altitude. 

(8) Calculation of fuel consumption during level flight over a specified time interval. 

(9) Conversion of speeds to those based or\ a different reference. 

(10) Determination of the gas law variables. 

(1 1) Computation of wind speed and direction and of ambient temperature. 

(12) Calculation of drag force. 

(13) Calculation of thrust force. 

(14) Computation of fuel flow. 

(15) Calculation of the slow- and fast-speed limits. 

(16) Conversion of altitudes to those based on a different reference. 

The branch architecture divides the remaining logic into four sub-functions, which are executed in 
sequence: 

(1) Data initialization and preliminary path processing. 

(2) Path calculation. 

(3) Evaluation of the path calculation. 

(4) Display of acceptable path. 

This sequence satisfies the processing flow requirements in subsection 4.1. Each branch in turn may be 
separated into sub-branches. This process can be continued down to many levels, although at the expense 
of execution time. For example, the calculation of the holding delay path consists of five levels. Figure 10 
illustrates the overlay architecture. A selection to be made by the overlay logic is represented by 
parentheses enclosing a list of the candidate modules that are grouped as one overlay branch. Underscored 
names represent a group of functionally related routines, which are listed elsewhere in the figure. Groups 
of library routines are delimited by colons. All module functions are summarized in Appendix B. 
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GENERL: 

SPEEDS: 

PERFRT: 

BLKDAT: 

PRFCLC: 

CALMDL: 

RLOAD: 

RLOAD1: 

RLOAD2: 

INITL: 

PROFIL: 

RWYPR: 

SEGCLC: 

CHGSPD: 

CHEFA: 

CHEFD: 

CHACC: 

CHDEC: 

DECNT: 

RINSRT: 

SEGDC: 

SEGAC: 

DCTTLS: 

DTSEG: 

RDSEG: 

DSEGC: 

DGPER: 

RTSEG: 

HIGHPR: 

HPRCLC: 

METER: 

HICLC: 

DELAYS: 

INFO: 

HLDALS: 

HOLD: 

RVPTH: 

HLDPRO: 

STACK: 

STPTRN: 

HALTM: 

HDCNT: 

LEGS: 

TURNS: 

STRTCH: 

EVPRF: 

DISPLY: 

DETDIS: 

SUMDIS: 

ATMFXN: 

MODELS: 

ALTCON: 

PERFMN: 

RDRAG: 

FUEL: 

THRUST: 


LFMPD— BLKDAT — GENERL — SPEEDS — PERFRT — (PRFCLC. PROFIL.EVPRF DISPLY) 

STRPTH — STRNII — VALDTE — LI NR EG — NWPIDF — HCRIT — CRFUEL 

PRFLIB/LB:TMACH:CAS:CMACH:TAS:GNDSPD:GTAS:DRIFT:AWCMP 

ATMFXN — MODELS — PERFMN— ALTCON 

FILES— CONST— CONTRL 

RDCALT — ( CALMDL . RLO AD . INITL ) 

ATMOS — ADDTRP — CONVRT — CORCPT — CORCPW — GTFCST — LINMDL — FCSTKW — FCSTKT 
LOADAR— ( RLOAD1 . RLOAD2 ) 

WEIGHT — READIN — GTPRF — RVGEOM — ALTSPD — ERRAS — VLDAS — ROUTE— ERRRTE — 
VLDRTE 

IDTFWP — ASGNV — CSFIX — ASGNA — CONTPA 
ICESET — STGWT — HCCALC 
EXCCAP— RODALT— ( RWYPR. HIGHPR ) 

RWYPF — SEGCLC 

ITYPE— SEGCAL— (SEG1 . CHGSPD . DECNT ) 

REMOVE — ( CHEFA . CHEFD . CHACC . CHDEC) 

EFACC — SEG3 — (ADJA1 .ADJA2) 

EFDEC—SEG2— ICING— (ADJD1.ADJD2) 

ACCEL— SEG3— (AD JA1 .ADJA2) 

DECEL— SEG2— ICING— (ADJD1-, ADJD2) 

SEG4— ( RINSRT.SEGDC . SEGAC . DTSEG ) 

INSPOD— INSRTT— INSERT 

SEG4DC— ADJTLD— DCTTLS — ICING— (ICPER.TSTPER) 

SEG4AC— ADJTLA— DCHLS— ICING— (ICPER.TSTPER) 

DSAS — PFCAS — DCTTOT 
( RDSEG . RTSEG) 

DSEG4A— DSEG4B— DSEG4I— (DFCTMX.DSEGC.SPOILF.NIREC.VAREC) 

DSEG4C— PFCAS— (ICING. DSAS. DGPER.DCTTOT.ADJTLD.RODEND) 

(DGPERT. DGPER I) 

TSEG4A — TSEG4B — THRSTF — ADJTLD — DCTTLS — THPER — NIREC 
HIGHPF—ETIME— HPRCLC — ( METER . DELAYS ) 

DESCAS — COMPCI — DMACH — SLMACH 

TIME — IDMFWP — FAMACH — MSRCH — RDMTRS — RDMFT — TIMERQ — HICLC 

HPD— SEGCLC 

DELAY— PSMTRF— TREV— ( INFO, HOLD . STRTCH ) 

HLDINF— HLDAl^— HLDSPD— IDHWPT— INSHF— INSERT 
HLDNOA — HLDOA — HLDSTA — HLDSA 
HLDPRF — ( RVPTH . HLDPRO . STACK ) 

RVPATH— BSACOS— HEWPT— HFIPA— TSACOS— INSRTT— INSERT 
HPRHLD— SEGCLC 

STINF — HDWND — HLDALT — NUMCIR — STPTRN 
STPAT — ( HDCNT . LEGS .TURNS. HALTM) 

HALTMF — BNKANG 

DCTHA— DSAS1— DCTTOT— AD JTL1— ICING— (ICPER.TSTPER) 

TLEG1— TLEG2— GAMMA 
TTURNS — TREVA — TREVB — AALPHA 
PATHST— PSOFST— RVPAPS— INSRTT— INSERT 
ATCAPP— EVGWT 

REPORT— IROUND— DETDIS — SUMDIS 
NUMID— PDDIS — CONMSL — DETHLD — DISDTI 
SUMARY— SUMDLY— SEGTOT— MSEC 
PRFLIB/LB:DELTA:RHO:SIGMA: THETA 
PRFLIB/LB:IALTM:WNDSPD:WNDDIR:TEMPC 
TRUALT — CMSLPA — PAMSL 

RDRAG — THRUST — FUEL — PRFLIB/LB:VFAST VSI OW 

PRFLIB/LB:CDCLCDSPLR:DRAG 

PRFLIB/LB:FUELFI:FUELFL 

PRFLIB/L8:ALTC:EPR:THRSTN:TSTIDL:TSTMCL:TSTMCR:TSTPAR 


Figure 10. Airborne LFM/PD Overlay Architecture 
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5.3 RECOMMENDED PATH-REVISION CAPABILITIES 


The algorithm currently has a general path-revision capability that allows interactive input changes to be 
made in the fast-time algorithm. These changes represent the input modes of the airborne version. The 
capability is invoked when changes are required to the currently loaded inbound path (but not to the 
default destination airport). Its basic format is the specification of new path segments and their associated 
constraints from the innermost (closest to the aimpoint) waypoint outbound. An electronic horizontal 
situation indicator (EHSI) is assumed to aid the flight crew in viewing the airplane’s current position in 
relation to the waypoints along the intended route of flight. 

First, the innermost path segment to be retained is identified. The algorithm then requires the names of all 
waypoints (published or pilot-defined) outbound that constitute the new sequence of waypoints. The last 
input waypoint is considered to be the new entry fix. Then, after the waypoint input session, the 
corresponding segment-magnetic courses and distances are required, followed by the maximum and 
minimum altitude and airspeed constraints at all inclusive waypoints. The algorithm automatically checks 
the validity of all inputs, consisting of the following: 

(1) All magnetic courses must be between 0 and 360 deg inclusive. 

(2) All segment distances must be greater than zero nmi but less than a predefined maximum distance. 

(3) All altitude constraints (both maximum and minimum) must be greater than zero ft but less than the 
service ceiling altitude. 

(4) All speed constraints are zero knots calibrated airspeed (kcas) or greater, but less than the fast-speed 
performance limit at cruise altitude for the current airplane weight. 

(5) The minimum altitude constraint at a waypoint must not exceed the maximum altitude constraint. 

(6) The maximum or minimum altitude constraint at a waypoint cannot be higher than the corresponding 
one at the next outbound waypoint where a constraint is specified. 

(7) The speed constraint at a waypoint cannot exceed that of the next outbound waypoint where a 
constraint is defined. 

The algorithm allows corrections to be made in case of erroneous inputs. 

The change procedure now implemented requires some improvement in convenience. It should be 
possible, for example, to change altitude and speed constraints at a waypoint, delete a waypoint, or specify 
a lateral offset without the complex procedure described above. Function keys on a CDU are assumed to 
permit access to the appropriate input modes. The above procedure is also inappropriate when a tactical 
command is required to change direction immediately, such as “direct to,” “fly a specified heading,” or 
“hold at present position.” Expediency precludes a time-consuming input process but should not diminish 
the advantages of computing a time-controlled profile, which requires a well-defined entry fix. 

The following subsections discuss recommended additional path-revision capabilities. It should be noted 
that a waypoint required as an input may be specified in one of three ways. 
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(1) Name of the published waypoint can be given. Its location (latitude and longitude) is pre-stored in 
the navigation data base. 

(2) Latitude and longitude of a waypoint not contained in the navigation data base can be specified. A 
name (alphanumeric string) will be assigned by the computer or can be entered by the pilot via the 
CDU. 

(3) Radial and distance from an input navigational aid or any waypoint stored in the navigation data base 
can be defined. The location of the navigational aid is pre-stored in the navigation data base. The 
waypoint name will be pilot-entered or computer-assigned, and its latitude and longitude computed. 

5.3.1 AIRPORT CHANGE 

This capability is already assumed to be part of the general FMC software capability. The algorithm 
currently asks for an airport selection and then a selection of a profile descent path for that airport. Table 1 
(subsection 4.4) suggests that the airport and path selection be entered by the flight crew prior to departure 
from the origin airport (preflight processing). This requires that the initialization process in the algorithm 
be restructured to display the default destination airport and ask for pilot confirmation. 

5.3.2 ARRIVAL PATH CHANGE 

This revision option is to be used when a different meter fix than the current one is required. If another 
airport selection is made, the chosen descent path must be specified accordingly. If another descent path at 
the same airport is needed, the current version of the algorithm should be restructured to display the 
default path and ask for pilot confirmation prior to an input procedure handling the change. 

5.3.3 CHANGES TO THE LATERAL DESCENT PATH 

This capability differs from the previous one, since the current meter fix is to be retained. Waypoint 
insertion, waypoint deletion, waypoint holding, “direct to” path linkage, lateral path offset, and changes 
to altitude and speed constraints constitute the choices to be provided under this option. 

5.3.3.1 Waypoint Insertion 

One or more waypoints not contained in the original flight plan may be inserted. This requires the 
identification of the beginning and ending waypoints of the original flight plan and the specification of the 
new intervening waypoints. A new waypoint may be specified either by entering its published name (the 
navigation data base contains its inertial coordinates and ATC constraints, if applicable) or defining the 
inertial coordinates (the pilot or computer will assign a name). When a new waypoint is defined, any 
applicable speed and altitude constraints also should be specified. 

5.3.3.2 Waypoint Deletion 

The waypoint deletion option refers to removing one or more waypoints from the flight plan and is to be 
differentiated from a “direct to” function. The currently implemented path-revision function can 
effectively perform this capability by defining the new flight plan, waypoint by waypoint, but omitting the 
waypoints to be removed. The input procedure would be greatly simplified, however, if the waypoints to 
be deleted could be named. 
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5.3. 3.3 Waypoint Holding 


Holding can be conducted at a future waypoint (either published or pilot-defined) or at present position. 
Note that there is an operational distinction between this type of holding and that generated by a 4D 
airplane to absorb ATC delay. The latter is described in detail in Reference 2. The required-pilot inputs, to 
hold at a future waypoint, consist of the name of the holding fix, entry altitude, holding speed, and turn 
direction. When holding at present position is activated, the algorithm assumes that present position is the 
holding fix, the current altitude is the entry altitude, current speed is the holding speed, and right is the 
turn direction. 

5.3.3.4 “Direct to” Waypoint 

The “direct to” function is used for tactical reasons (safety, avoidance of bad weather or path shortening). 
Its execution changes the airplane path from present position. The lateral navigation function will 
immediately steer the airplane onto a direct course to the specified waypoint. For this reason, profiles 
requiring a specific speed schedule to absorb the requisite delay in making good a MFT target will not be 
generated, although fuel-optimum profiles with no time constraints (no metering in effect) can still be 
calculated. For reasons of convenience, the “direct to” waypoint should be one already stored in the 
navigation data base. 

5.3.3.5 Lateral Offset 

A lateral offset function can be executed immediately or incorporated in a strategic revision to the flight 
plan. As in the previous option, use of this function as a tactical maneuver will preclude the algorithm 
from calculating a time-controlled profile. For expediency, the flight crew input should consist only of an 
offset distance and direction. The lateral path profile should be parallel to the nominal path until a 
“recapture” command is issued or another path revision function is engaged. 

If the offset configuration is known sufficiently ahead of path engagement, flight crew inputs should 
consist of offset distance and direction and specification of the waypoint at which the offset path is to 
recapture the nominal path. A time-controlled profile can still be computed when this offset mode is 
engaged. Any speed and altitude constraints at the bypassed original waypoints are assumed to apply at 
their paired offset waypoints. 

5.3.4 Changes to the Vertical Descent Path 

These types of changes include altitude constraint modifications, speed constraint modifications, and 
adjustments to correct for an early or late TOD. 

5.3.4.1 Changes to Altitude Constraints 

Modifications at waypoints already part of the flight plan should be made directly on the appropriate CDU 
display page. Changing constraints at new waypoints should be a part of the waypoint insertion process 
(subparagraph 5.3.3. 1). 


r 
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5.3.4.2 Changes to Speed Constraints 


As in the previous section, the speed constraint may be changed at an existing waypoint directly on the 
CDU or be made as part of the waypoint insertion process (subparagraph 5.3.3. 1). 

S.3.4.3 Corrections for Early or Late TOD 

A new path segment may be required if unpredicted winds are encountered after the original path has been 
engaged. Depending on whether time control is required or not, changes to the descent path require one of 
two solutions when the flight management system (FMS) has determined that the descent winds have been 
incorrectly estimated. For a 3D path, a path segment using added thrust or spoiler drag may be required to 
intercept the nominal path. When this mode is activated on the CDU, the algorithm will automatically 
identify the next waypoint. An altitude and speed at the waypoint have already been defined in the 
previous calculation and will serve as the targets for the revised segment. 

For a 4D path, the pilot may activate the algorithm to recompute a new path and speed schedule in order 
for the airplane to arrive at the meter fix at the originally assigned time. 

5.3.5 CHANGES TO THE MFT 

The new MFT should be entered on the CDU. The algorithm will subsequently compute a new path with a 
speed schedule appropriate to making good the new time. 
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6.0 SYSTEM INTERFACE REQUIREMENTS 

The path definition algorithm described in this document will be one element of an FMS. The algorithm 
developed is assumed to reside in an FMC and interact with (1) the pilot via the CDU, (2) the lateral path 
processing module in the FMC, and (3) the guidance and steering module in the FMC. The guidance and 
steering module will, in turn, interface with the autopilot and autothrottle system. Other path-definition 
algorithm interfaces will include sensors (air data, IRS, engine instruments, etc.) and off-line navigation, 
airframe and engine data bases. A schematic of one possible architecture is illustrated in Figure 11. The 
following interface requirements were assumed in the airborne algorithm design. 

6.1 CDU INTERFACE REQUIREMENTS 

A default set of input options is available for the path-definition algorithm once the destination airport is 
identified. The path-computation process must be initiated by the pilot and, if desired, engaged. All 
non-default options for the descent path must be selected from available menus displayed on the CDU. 
Parameter values, where required, will be requested and must be entered via the CDU. A series of 
operational scenarios is contained in Appendix A. 

Results of the algorithm path-computation process will be presented to the flight crew for review on the 
CDU. Summarized information, as shown by the examples in Tables 2 and 3, will be available. 


Required CDU entries will be minimized, where possible, to provide minimum impact on flight-crew 
workload. 


6.2 LATERAL PATH-PROCESSOR REQUIREMENTS 

The path-definition algorithm assumes a lateral (x,y) path over the ground in terms of great circle arc 
segments of defined course and distance and turn circle arcs between great circle arcs. If waypoints are 
defined in terms of latitude and longitude, a set of equations to convert to course and path distance will be 
required. 


The path-distance equations must consider the turn segments. Implications of ignoring these terms in the 
calculations are threefold: (1) a path-distance error between waypoints is introduced, (2) an error is 
introduced in thrust required to maintain level flight, and (3) a ground-speed (here time) error, in turning, 
is introduced. For the expected range of approach conditions, these errors are significant. The expected 
path-distance error can be computed as (2V 2 /g tan <f>)[tan (A ^/2)-Ai£/2] where V is ground speed, <f> is the 
bank angle and A^ is the course change (in radians). For a 45° course change at 250 kcas at 10,000 feet 
and a 22.5° bank, the path error will be about .1 nmi. 

6.3 GUIDANCE AND STEERING REQUIREMENTS 

The path-definition algorithm defines the ideal path that the airplane should follow in executing a 
fuel-efficient descent in a time-based ATC environment. To fly to this path, special guidance laws will be 
required to interface with the autopilot and autothrottle. 
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Figure 11. System Interface Diagram 



Table 2. Sample Profile Descent Path Array 





CIVET 25 

Profile Descent 





Segment 

Mag 

Distance 

Time 

Altitudes 

Speeds (CAS) 

Fuel 

Description 

Course 

(nmi) 

(sec) 

Begin 

End 

Begin 

End 

Ob) 

PGS 

ECSFIX 

227 

5.5 

47.1 

35000 

35000 

259 

228 

14 1 

ECSFIX 

ABREE 

227 

114.5 

1051.1 

35000 

35000 

228 

228 

1203.9 

ABREE 

DIKES 

226 

15.0 

137.6 

35000 

35000 

228 

228 

156.7 

DIKES 

TOD 

226 

23.2 

212.5 

35000 

35000 

228 

228 

241 4 

TOD 

EMMEY 

226 

.8 

7.7 

35000 

34754 

228 

229 

2.3 

EMMEY 

BAIRS 

226 

24.0 

221.8 

34754 

26952 

229 

250 

66.5 

BAIRS 

TP 

226 

22.0 

224.7 

26952 

19681 

250 

250 

67 4 

TP 

CIVET 

248 

8.0 

88.4 

19681 

16771 

250 

250 

26.5 

CIVET 

ARNES 

248 

18.0 

214.2 

16771 

10000 

250 

250 

73.4 

ARNES 

POD2 

248 

1.0 

12.1 

10000 

10000 

250 

250 

16.3 

POD2 

CSFIX1 

248 

7.9 

100.7 

10000 

7000 

1 250 

250 

41.8 

CSFIX1 

BASET 

248 

2.6 

37.4 

7000 

7000 

1 250 

210 

15.9 

BASET 

DOWNE 

248 

7.3 

115.3 

7000 

4361 

210 

210 

51.1 

DOWNE 

HUNDA 

248 

2.8 

45.3 

4361 

3436 

210 

210 

i 21.5 

HUNDA 

CSFIX2 

248 

3.2 

52.9 

3436 

1892 

210 

210 

26.3 

CSFIX2 

LIMMA 

248 

1.7 

30.4 

1892 

1892 

210 

180 

15.5 


Descent Requirements 


Starting at BASET 21.9 percent of maximum spoiler drag must be added for the segment to DOWNE to maintain 
the profile 


co 

to 


Starting at HUNDA 100.0 percent of maximum spoiler drag must be added for the segment to CSFIX to maintain 
the profile 



Table 3. CIVET 25 Summary 


Entry Fix 
Meter Fix 
Aimpoint 


CIVET 25 Summary 

PGS 
CIVET 
LIMMA 


Profile Distance 257.5 nmi 

Entry Information 

Cruise Speed .765 Mach (259 kcas) 
Change Speed to 228 kcas at PGS 

Descent Information 

Top of Descent 99.3 nmi from LIMMA 
Descent Schedule .682 Mach/250 kcas 

Meter Fix Information 

Altitude at CIVET 16771 

Airspeed at CIVET 250 

Aimpoint Information 


Altitude at LIMMA 
Airspeed at LIMMA 
Gross Wt at LIMMA 


1892 

180 

82959 LB 


Segment Totals 


Total Time: 43 min 19.1 sec 
Total Fuel: 2040.7 lb 




Control objectives in the descent are fourfold: (1) time at the meter fix, (2) altitudes at the aimpoint and 
intermediate waypoints, (3) airspeeds at the aimpoint and intermediate waypoints, and (4) minimum fuel 
use. 

The guidance and steering functions should accommodate complex descent paths with intermediate 
level-offs (at constant airspeed or in deceleration), partial-th rusted descents, spoiler-commanded descents, 
as well as clean-idle descents. A typical path employing clean-idle descents is illustrated in Figure 4. 

Guidance and steering should provide the capability to capture the descent path when the descent has 
begun early or late, when an intermediate level-off is required by ATC, etc. 
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7.0 CONCLUSIONS 


The requirements for an airborne version of the LFM/PD algorithm have been specified. Additional 
functional capabilities beyond those of the baseline fast-time version are needed, primarily to 
accommodate pilot inputs and path revisions. Greater algorithm flexibility has been developed in allowing 
metering at any published waypoint, removing previous distance limits over which changes of speed and 
spoiler drag descents can take place and developing an algorithm that is airplane-type independent. 
Improvements in program efficiency have been achieved by a faster-converging, descent-speed search 
technique for metered profiles and by using larger integration step sizes for all path computations. 

The feasibility of implementing the airborne algorithm in a restricted-core computer has been 
demonstrated with the overlay design. The current algorithm version satisfies the requirements of 
processing flow and data base architectures, as detailed in subsections 4. 1 through 4.3. Additional work is 
required to develop the flight crew interface logic that is recommended in subsection 4.4. The algorithm 
currently has a path revision capability, but further enhancements have been recommended in subsection 
4.4. Work is also needed to incorporate the suggested implementation described in subsection 5.3. These 
functions define a tactical mode of 4D navigation to supplement the basic strategic mode resident in the 
current airborne algorithm. Timely responses to changes in the operational ATC environment and to the 
vagaries of weather are desirable and, in most cases, practicable, while retaining the attributes of time 
navigability. 
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APPENDIX A 


TNAV OPERATION IN THE 
EN ROUTE METERING ENVIRONMENT 

The development of the en route metering program and implementation within the national airspace 
system (NAS), together with the LFM/PD 4D time navigation (TNAV) capability, suggest the need to 
consider procedures to exploit these capabilities for the benefit of the ATC system as well as for the 
equipped airplane. The following scenarios, representing operations in the Denver air route traffic control 
center (ARTCC), are an attempt to describe the expected operation of TNAV clearances. 

Assumptions in the development of the scenarios include: 

(1) The en route metering program, as implemented at the Denver ARTCC, is in effect. 

(2) No other users are equipped with TNAV systems; current ATC system capabilities are assumed. 

(3) Three levels of delay apply for varying traffic loads at Denver. The summary flow management 
system features and associated clearances for the 4D airplane are listed for low, intermediate, and 
high levels of delay: 

(a) Low delay: pilot’s discretion descent to the meter fix 

(b) Intermediate delay: ATC-assigned time to the meter fix if no conflicts are projected 

(c) High delay: no ATC-assigned times unless aircraft are projected over low-traffic fix. 

To develop the alternative level-of-delay scenarios, the KEANN 26 low-profile descent was selected as a 
baseline. Each scenario was developed assuming the National Aeronautics and Space Administration 
(NASA) 515 B-737 performance characteristics and KEANN 26 low-profile approach data. The nominal 
lateral-approach path is shown in Figure 12. 

Figure 13 is a diagram, which provides an overview of the logic that illustrates how the 4D airplane could 
be operated in Denver ARTCC’s en route metering system with a minimum of change to the present 
ground system operation and procedures. The scenario is based on the logic sequence shown. 

The equipped airplane will enter the flow management time-based metering system at cruise altitude and 
speed, and at a distance typically about 150 nmi from the arrival meter fix. The following is a scenario of 
ATC and airplane actions (A) and communications (C): 

ATC: (A) ATC will enter the flight into the metering system. Using an estimated time to reach 

the meter fix, based on present flight data, ATC will calculate a tentative MFT. 

Airplane: (C) “Center, NASA 515 requests TNAV arrival.” 

Note: Coordination of as many as four control positions (two high-altitude sectors, the 
low-altitude arrival sector, and the metering position) may be required to accommodate the 
TNAV arrival request. 
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WIGGI 
Holding Fix 


Figure 12. Denver Stapleton KEANN 26 Approach 



Flight 

Plans 


Note: 



Figure 13. TNAV Use in En Route Metering 
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IF METERING IS NOT IN PROGRESS 


ATC: (C) “NASA 515, Center, metering is not in progress. Expect pilot’s discretion descent.” 

Airplane: (C) “Center, NASA 515, understand. Expect pilot’s discretion descent” 

(A) Pilot will plan for minimum-fuel descent using the expected arrival clearance (e.g., 
pilot’s discretion descent, runway in use, and published profile descent, or expected arrival 
route and altitude, based on experience). This will be a clean-idle descent at minimum fuel. 

A description of events associated with the pilot’s discretion descent is contained in Table 4 using the 
KEANN approach geometry at Denver and the NASA 515 performance characteristics. 

IF METERING IS IN PROGRESS WITH HOLDING (AT THIS FIX) 

ATC: (C) “NASA 515, Center, be' advised holding in progress. Expect further clearance ” 

Airplane: (C) “Center, NASA 515, understand holding in progress. Expect further clearance” 

(A) Pilot will plan for minimum-fuel descent using the expected-arrival clearance. 

IF METERING IS IN PROGRESS WITHOUT HOLDING, BUT A TNAV CLEARANCE IS NOT 
DESIRABLE DUE TO POTENTIAL CONFLICT WITH OTHER TRAFFIC 

ATC: (C) “NASA 515, Center, TNAV clearance is denied due to traffic. Expect further 

clearance ” 

Airplane: (C) “Center, NASA 515, understand TNAV arrival denied due to traffic. Expect further 

clearance ” 

(A) Pilot will plan for minimum-fuel descent using the expected-arrival clearance. 

IF METERING IS IN PROGRESS WITHOUT HOLDING, CONFLICT NOT LIKELY; A TNAV 

CLEARANCE WILL BE AUTHORIZED 

ATC: (C) “NASA 515, Center, cleared for TNAV arrival, KEANN intersection at XXXX (time), 

runway 26L, low-profile descent, descend to FL 240 at pilot’s discretion.” 

Airplane: (C) ^Center, NASA 515, understand cleared for TNAV arrival, KEANN at XXXX (time), 

runway 26L low profile, descend to FL 240 at pilot’s discretion.” 

(A) Pilot enters the assigned MFT into the FMS. The FMS will define the path and speed 
profile to meet the assigned MFT. 

TNAV-descent events for the KEANN approach and the NASA TCV performance characteristics are 
contained in Tables 5 and 6. 



Table 4. Scenario for En Route Metering, Low-Delay Level, Pilot’s Discretion Descent 


Time 

(hr:mln:sec) 

Distance 

(nml) 

Altitude 

(«) 

Originator 

Event 

11:56:00 

225 

35000 

NASA 515 

Requests TNAV clearance to Denver Stapleton 




Center 

Transmits clearance to NASA 515: 

(a) KEANN low profile descent to Runway 26L 

(b) No time constraints 

11:58:00 

210 

35000 

NASA 515 

Clearance acknowledged 

Clearance entered in flight management system 
minimum-fuel descent approach path predicted 

12:00:00 

195 

35000 

NASA 515 

Descent engaged at entry fix 
Speed change from 259 to 223 kcas 

12:15:29 

94 

35000 

NASA 515 

Top-of-descent for predicted path reached 
Throttles to idle, descent initiated 

12:23:21 

45 

19050 

NASA 515 

Crosses meter fix and resumes descent 




Center 

Transmits approach control frequency to NASA 515 




NASA 515 

Contacts approach control for approach clearance 




Approach 

Transmits clearance to NASA 515: ILS Runway 26L, FLOTS 
direct WATKI 

12:25:57 

31 

14000 

NASA 515 

Level-off to inner fix altitude 
Decelerate from 250 to 210 kcas 

12:26:39 

28 

14000 

NASA 515 

Turn at FLOTS. fly direct to WATKI (to intercept final approach) 
and resume descent 

12:29:35 

16 

10000 

NASA 515 

Turn to final at WATKI. continue descent 

12:32:1 1 

8 

7200 

NASA 515 

Level off and decelerate from 210 to 180 kcas 
Begin descent to runway from ALTUR 


Descent time 34 min 51 sec 

Descent distance 195 nmi 

Descent fuel 1396 lb 



Table 5. Scenario for En Route Metering, Intermediate-Delay Level, TNAV Descent 


Time 

(hr:mln:sec) 

Distance 

(nmi) 

Altitude 

an 

Originator 

Event 

1 1:56:00 

227. 

35000 

NASA 515 

Requests TNAV clearance to Denver Stapleton 




Center 

Transmits clearance to NASA 515: 

(a) KEANN low profile descent to Runway 26L 

(b) Meter fix time assigned 12:21 

11:50:00 

212 

35000 

NASA 515 

Clearance acknowledged 

Clearance entered in flight management system 
Metered descent approach path predicted 

12:00:00 

197. 

35000 

NASA 515 

Descent engaged at entry fix 
Speed change from 259 to 258 kcas 

12:15:07 

113. 

35000 

NASA 515 

Top-ol-descent reached for predicted path 
Throttles to idle, descent initiated 

12:19:29 

55 

19100 

NASA 515 

Level-off at meter fix altitude 
Decelerate from 328 to 250 kcas 

12:20:45 

47. 

19100 

NASA 515 

Crosses meter fix and resumes descent 




Center 

Transmits approach control frequency to NASA 515 




NASA 515 

Contacts approach control 




Approach 

Advises NASA 515 to expect radar vectors at FLOTS due to traffic 

12:23:1 1 

33 

14000 

NASA 515 

Level-off to inner fix altitude 
Decelerate from 250 to 210 kcas 

12:23:53 

30 

14000 

NASA 515 

Crosses FLOTS 




Approach 

Transmits clearance to NASA 515: left turn to heading 140 to 
intercept localizer, cleared for ILS Runway 26L 




NASA 515 

Acknowledges clearance, turns to heading, resumes descent 

12:26:49 

16 

10000 

NASA 515 

Intercept localizer, continue descent 

12:29:24 

8 

7200 

NASA 515 

Level-off and decelerate from 210 to 180 kcas 
Begin descent to runway from ALTUR 


Descent time 32 min 4 sec 

Descent distance 197 nmi 

Descent fuel 1583 lb 




Table 6. Scenario for En Route Metering, High-Delay Level, TNAV Descent With 

Holding 


Time 

Distance 

Altitude 

Originator 


(hr:m(n:sec) 

(nml) 

(»> 

Event 

11:56:00 

231 

35000 

NASA 515 

Requests TNAV clearance to Denver Stapleton 




Center 

Transmits clearance to NASA 515: 

(a) KEANN low profile descent to Runway 26L 

(b) Meter fix time assigned 12:40 

11:58:00 

216. 

35000 

NASA 515 

Clearance acknowledged 

Clearance entered in flight management system 

Metered descent approach path predicted with holding at 21000 

feet at WIGGI 

Holding altitude request transmitted to ATC 




Center 

Clearance to hold at requested altitude 

12:00:00 

201. 

35000 

NASA 515 

Descent engaged at entry fix 
Speed change from 259 to 210 kcas 

12:13:14 

122. 

35000 

NASA 515 

Top-of-descent reached for predicted path throttles to idle, 
descent initialized 

12:22:46 

71. 

21000 

NASA 515 

Level-off to begin holding fix entry procedure 

12:24:51 

61 

21000 

NASA 515 

Initiate holding at WIGGI, advises Center 

12:37:56 

61 

21000 

NASA 515 

Depart holding at WIGGI, resume descent to meter fix, 
advises Center 

12:39:35 

54. 

19100 

NASA 515 

Level-off at meter-fix altitude 
Accelerate from 210 to 250 CAS 

12:40:09 

51 

19100 

NASA 515 

i 

Crosses meter fix and resumes descent 




Center 

Transmits Approach Control frequency to NASA 515 




NASA 515 

Contacts Approach Control 




Approach 

Advises NASA 515 to expect radar vectors at FLOTS due to traffic 

12:42:36 

37. 

14000 

NASA 515 

Level-off to inner-fix altitude 
Decelerate from 250 to 210 kcas 



Table 6. Scenario for En Route Metering, High-Delay Level, TNAV Descent With 
Holding (Concluded) 


Time 

Distance 

Altitude 

Originator 

Event 

(hr:mln:sec) 

(nmi) 

(») 

12:43:17 

34 

14000 

NASA 515 

Crosses PLOTS, resumes descent 




Approach 

Transmits clearance to NASA 515: left turn to heading 140 
due to traffic 




NASA 515 

Acknowledges clearance, turns to heading 




Approach 

Transmits clearance to NASA 515: further left turn to heading 124 
due to traffic, intercept localizer, cleared for ILS approach 
Runway 26L 




NASA 515 

Acknowledges clearance, turns to heading 

12:46:40 

20 

10000 

NASA 515 

Intercepts localizer, continues descent 

12:50:34 

8 

7200 

NASA 515 

Level-off and decelerate from 210 to 180 kcas 
Begin descent to runway from ALTUR 


Descent time 
Descent distance 
Descent fuel 


53 min 14 sec 
201 nmi 
2411 lb 














APPENDIX B 


AIRBORNE ALGORITHM MODULES 

The following is a list of all the airborne LFM7PD modules and their functional descriptions: 

Module Name Function 

AALPHA Calculates angle between inbound and outbound leg headings 

ACCEL Controls path computation over distance required for acceleration before 

the aimpoint 

ADDTRP Adds tropopause temperature and wind data to weather models 

ADJA1 Adjusts path computation for entry fix acceleration segment when 

required final speed is exceeded 

AD JA2 Adjusts path computation for entry fix acceleration segment when distance 

limit is exceeded 

ADJD1 Adjusts path computation for entry fix deceleration segment when 

required final speed is exceeded 

ADJD2 Adjusts path computation for entry fix deceleration segment when 

distance limit is exceeded 

ADJTL1 Adjusts altitude, time, fuel, and weight totals at the end of a descent 

calculation between holding altitudes 

ADJTLA Adjusts segment totals for altitude-constrained descents for time, fuel, and 

distance 

AD JTLD Adjusts segment totals for distance-constrained descents for time, fuel, and 

altitude 

ALTC Determines corrected net-thrust differential due to increased F n /8 with 

altitude, given Mach number and altitude 

ALTMTR Supplies station altimeter setting 

ALTSPD Obtains altitude and speed constraints at each waypoint 

ASGNA Assigns the ATC-constrained maximum altitudes for all waypoints 

ASGNV Assigns the ATC airspeed constraints from aimpoint to meter fix 

ATCAPP Requests ATC approval for required deviations from geometry-defined 

minimum-altitude restrictions 
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Module Name 


Function 


ATMOS 

AWCMP 

BNKANG 

BSACOS 

CAS 

CDCL 

CDSPLR 

CMACH 

CMSLPA 

COMPCI 

CONMSL 

CONTPA 

CONVRT 

CORCPT 

CORCPW 

CRFUEL 

CSFIX 

DCTHA 

DCTTOT 


Controls construction of wind and temperature models 
Computes along-track wind magnitudes 
Computes holding bank angle 
Inserts change-of-speed fix after stack exit 

Computes calibrated airspeed, given altitude, and Mach number 

Determines coefficient of drag, using stored drag polars, given Mach 
number, and coefficient of lift 

Determines incremental coefficient of drag available as a function of 
equivalent airspeed 

Converts a calibrated airspeed at altitude to a Mach number 

Converts Mean Sea Level (MSL) value to pressure altitude, using 
station-pressure correction 

Completes altitude and airspeed information in the path array when the 
calculation reaches cruise altitude 

Controls conversion of pressure altitudes to MSL altitudes 

Controls conversion of MSL altitudes to pressure altitudes 

Transforms wind forecast from rho-theta system to "to wind” zonal and 
meridional components 

Obtains temperature at cruise altitude; computes error function; applies 
error function to forecast 

Obtains wind at cruise altitude; computes error function; applies error 
function to forecast 

Computes fuel used in level cruise, given time 

Inserts change-of-speed fixes before waypoints at which an acceleration or 
deceleration is required 

Controls calculation of idle-descent fuel and time between holding 
altitudes 

Totals time, distance, and fuel for each altitude step in a descent 
calculation 
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Module Name 


Function 


DECEL 

DELAY 

DELTA 

DESCAS 

DETHLD 

DFCTMX 

DGPERI 

DGPERT 

DISDTI 

DMACH 

DRAG 

DRIFT 

DSAS 

DSAS1 

DSEG4A 

DSEG4B 

DSEG4C 


Controls path computation over distance required for deceleration before 
the aimpoint 

Controls construction of delay profile 
Determines pressure ratio at given altitude 

Determines descent calibrated airspeed for a given critical altitude and 
Mach number 

Displays detailed holding requirements 

Determines maximum spoiler factor used in previous segments requiring 
drag 

Computes engine idle thrust, drag, and fuel flow for a altitude step in a 
descent calculation, given spoiler setting 

Computes thrust, drag, and fuel flow for an altitude step in a descent 
calculation, given spoiler setting and airplane turbine rpm (N x ) thrust 

Displays thrusted or spoiler descent requirements 

Determines equivalent cruise Mach that will transition at the critical 
altitude to the input calibrated airspeed 

Determines drag force, given the calibrated airspeed, altitude, gross 
weight, and flight path angle 

Calculates drift from true course due to wind 

Establishes altitudes and speeds for an altitude step in a descent 
calculation 

Calculates altitudes and speeds for an altitude step in a descent calculation 
between holding altitudes 

Computes drag required to satisfy altitude and distance-constrained 
descent 

Computes final altitude, time, and fuel for given drag and speed schedule 
over fixed distance 

Computes final energy state and position fordistance-constrained descent 
segment requiring drag 
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Module Name 
DSEG4I 

EFACC 

EFDEC 

EPR 

ERRAS 

ERRRTE 

ETIME 

EVGWT 

EXCAPP 

FAMACH 

FCSTKT 

FCSTKW 

FUELFI 

FUELFL 

GAMMA 

GNDSPD 

GTAS 

GTFCST 

GTPRF 

HALTMF 


Function 

Computes final energy state and position for descent segment(s) requiring 
drag 

Controls path computations over distance required for acceleration after 
entry fix 

Controls path computation over distance required for deceleration sifter 
the entry fix 

Determines engine EPR given corrected Nj, Mach number, and altitude 

Validates waypoint altitude and speed constraints 

Validates course and distance input data 

Computes total elapsed time for specified profile segment 

Evaluates aimpoint gross weight estimate by comparing entry-fix 
calculated gross weight with input value 

Sets profile termination flag 

Determines fastest Mach/CAS-descent within aeroperformance limits of 
the aircraft 

Determines forecast temperature at cruise altitude 

Determines forecast wind at cruise altitude 

Determines idle-fuel flow, given Mach number and altitude 

Determines fuel flow, given net thrust, Mach number, and altitude 

Computes angle between inbound true heading and wind 

Computes groundspeed, given altitude, true airspeed, and course 
information 

Computes true airspeed from groundspeed, true course, and wind 

Reads number of forecast altitudes and, for each altitude, the forecast wind 
direction and speed and forecast temperature 

Accesses selected path from random access file 

Computes fuel used at given holding altitude 
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Module Name 


Function 


HCCALC 

HCRIT 

HDWND 

HEWPT 

HFIPA 

HIGHPF 

HLDALT 

HLDENF 

HLDNOA 

HLDOA 

HLDPRF 

HLDSA 

HLDSPD 

HLDSTA 

HPD 

HPRHLD 

LALTM 

ICESET 

ICING 


Computes the critical altitude model (for transition from Mach to CAS 
schedule) as a function of true airspeed 

Determines critical altitude from model computed in HCCALC 

Verifies that headwind components do not compromise timing at all 
holding altitudes 

Inserts level segment prior to entering stack 

Controls distance, speed, and altitude constraint calculations for the 
holding elements in the path array 

Selects method of computing the high profile required to meet metering 
conditions 

Determines all holding altitudes between specified top and bottom 
altitudes 

Obtains inputs to initiate holding path calculations 

Determines closest ATC holding altitude to single airplane, computed 
optimum holding altitude 

Determines the closest holding altitude intersecting the calculated 
fuel-efficient profile at the holding fix 

Controls computation of the holding path 

Obtains valid single-altitude assignment 

Obtains valid holding airspeed 

Obtains assigned top and bottom stack altitudes 

Controls processing sequence in construction of profile from meter fix back 
to entry fix for a given speed schedule, using segment computation modules 

Coordinates construction of high-profile path with holding 

Determines weather model altitude closest to input altitude 

Obtains N 1 setting and icing altitude limits 

Tests whether anti-icing procedures are in effect 
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Module Name 
ICPER 

IDHWPT 

IDMFWP 

IDTFWP 

INSERT 

INSHF 

INSPOD 

INSRTT 

IROUND 

ITYPE 

LINMDL 

LINREG 

LOADAR 


MSEC 

MSRCH 

NIREC 

NUMCIR 

NUMID 

NWPIDF 

PAMSL 

PATHST 


Function 

Computes engine idle, clean-configuration thrust, drag, and fuel flow for 
an altitude step in a descent calculation 

Obtains valid holding fix identifier 

Obtains meter fix 

Determines transition fix of the current approach route 
Creates a new waypoint position in the path array 

Inserts holding fix when no published waypoints lie between entry fix and 
meter fix 

Inserts descent point distance, speed, and altitude into the path array 

Creates new positions in the segment total time and fuel arrays 

Rounds input variable to nearest integer for display purposes 

Determines the segment type, considering current airspeed and altitude 
and next waypoint’s airspeed and altitude constraints 

Constructs piecewise linear temperature or component wind model 

Solves the linear regression formula between two points 

Accesses geometry and weight; determines altitude and speed constraints 
at waypoints for desired path; assigns selected geometry to path array; 
obtains initial conditions for the descent profile; controls path geometry 
revisions 

Converts time in decimal minutes to minutes and seconds 
Determines descent Mach to meet time required at metering fix 
Compiles information for segments using thrusted or spoiler descents 
Computes initial number of circuits to absorb holding delay 
Numbers descent point and change-of-speed fix waypoints 
Determines numerical order of given waypoint 
Converts pressure altitude to MSL, using station pressure correction 
Controls computation of path-stretching parameters 
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Module Name 


Function 


PDDIS 

PFCAS 

PSMTRF 

PSOFST 

RDCALT 

RDMFT 

RDMTRS 

READIN 

REMOVE 

REPORT 

RETNII 

RETPTH 

RHO 

RODALT 

RODEND 

ROUTE 

RVGEOM 

RVPAPS 

RVPATH 

RWYPF 

SEG1 


Displays tabular course, distance, time, altitude, speed, and fuel 
information for profile 

Determines CAS for an altitude interval in a descent calculation, given a 
descent Mach 

Computes minimum circuit time, given wind, at optimum altitude 

Computes path-offset distance and leg times 

Obtains cruise altitude 

Obtains MFT assignment 

Determines metering status 

Obtains airport selection and profile descent path selection 

Eliminates unnecessary change-of-speed segments 

Formats and writes out the computed profile descent 

Retrieves arrays for spoiler and thrusted descents from temporary storage 

Retrieves path arrays for temporary storage 

Determines atmospheric density at given altitude 

Computes minimum altitude corresponding to a 500-feet per minute 
descent rate over the specified distance 

Provides profile-calculation-termination messages due to insufficient 
descent rate 

Inputs airway magnetic courses, variation and course distances 

Creates revised-path course, distance, and altitude constraints 

Revises path array to include offset waypoints required for path stretching 

Controls revision of high-profile geometry to accommodate holding 

Controls processing sequence in construction of profile from outer marker 
back to meter fix; uses segment computation modules 

Computes time and fuel for level , unaccelerated flight over a given distance 
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Module Name 


Function 


SEG2 

SEG3 

SEG4 

SEG4AC 

SEG4DC 

SEGCAL 

SEGTOT 

SIGMA 

SLMACH 

SPOILF 

STGWT 

STINF 

STPAT 

STRNII 

STRPTH 

SUM ARY 

SUMDLY 

TAS 


Computes time, distance, and fuel to decelerate between two CAS at 
constant altitude 

Computes time, distance, and fuel to accelerate between two CAS at 
constant altitude 

Computes time and fuel for a descent between two waypoints; calls other 
descent segment types, as required 

Computes final energy state and position for an altitude-constrained 
descent segment 

Computes final energy state and position for distance-constrained descent 
segment 

Initiates the segment calculations; accesses the segment calculation 
routines according to segment type 

Computes total time and fuel for profile 

Determines atmospheric-density ratio at given altitude, employing 
forecast temperature 

Determines slowest Mach/CAS descent within aeroperformance limits of 
the aircraft 

Determines percentage of available spoiler drag to converge on required 
distance and altitude 

Estimates aimpoint gross weight based on cruise, distance, and holding 
considerations 

Coordinates computation of stack information 

Controls calculation of holding times and fuels 

Stores arrays for spoiler and thrusted descents in temporary storage 

Stores path arrays in temporary storage 

Controls summary of important profile information 

Displays summary of holding information 

Computes true airspeed, given altitude, and Mach number 
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Module Name 

Function 

TEMPO 

Evaluates temperature model at given altitude to determine forecast 
temperature 

THETA 

Computes temperature ratio at given altitude 

THPER 

Computes clean-configuration thrust, drag and fuel flow for an altitude 
step in a descent calculation, given thrust setting 

THRSTF 

Determines percentage of available thrust to converge on required 
distance and altitude 

THRSTN 

Determines corrected net thrust, given Mach number and engine exhaust 
pressure ratio 

TIME 

Adds elapsed time to clock time 

TIMERQ 

Translates assigned MFT into the required elapsed time for the high 
profile, using estimated-entry fix time 

TLEGl 

Computes inbound leg time 

TLEG2 

Computes outbound leg time 

TMACH 

Computes Mach number for a given altitude and true airspeed 

TREV 

Computes time to complete one circular revolution at constant bank angle 

TREVA 

Computes outbound-turn time 

TREVB 

Computes inbound-turn time 

TRUALT 

Converts pressure altitude into geopotential altitude, using temperature 
lapse rate and the hydrostatic equation 

TSACOS 

Provides for change-of-speed fix prior to entering stack 

TSEG4A 

Computes thrust required to satisfy altitude and distance-constrained 
descent 

TSEG4B 

Computes altitude, time, and fuel for a given thrust and speed schedule 
over fixed distance 

TSTIDL 

Determines net thrust at a Mach number and altitude, given idle engine 
setting 

TSTMCL 

Determines maximum climb thrust available at an altitude and Mach 
number 
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Module Name 
TSTMCR 

TSTPAR 

TSTPER 

TTURNS 

VALDTE 

VAREC 

VFAST 

VLDAS 

VLDRTE 

VSLOW 

WEIGHT 

WNDDIR 

WNDSPD 


Function 

Determines maximum cruise thrust available at an altitude and Mach 
number 

Determines net thrust, given Mach number, altitude, and corrected rotor 
speed 

Computes thrust, drag, and fuel flow for an altitude step in a descent 
calculation, given a clean configuration and N 1 thrust 

Controls calculation of inbound- and outbound-turn times 

Validates input records after they have been displayed 

Records all altitude violations incurred during the descent-calculation 
process 

Determines high-speed CAS limit for a given altitude and weight 

Displays and accepts corrections to waypoint altitude and speed 
constraints 

Displays and accepts corrections to course and distance data 

Determines low-speed CAS limit for a given altitude and weight 

Obtains entry-fix gross weight acceptable within zero-fuel and maximum 
operating weights 

Evaluates wind model at given altitude to determine wind direction 

Evaluates wind model at given altitude to determine magnitude of wind 
velocity 
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